Skip to content

LCORE-3027: Debug skills E2E#2138

Open
jrobertboos wants to merge 1 commit into
lightspeed-core:mainfrom
jrobertboos:lcore-3027
Open

LCORE-3027: Debug skills E2E#2138
jrobertboos wants to merge 1 commit into
lightspeed-core:mainfrom
jrobertboos:lcore-3027

Conversation

@jrobertboos

@jrobertboos jrobertboos commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Description

Add debug print statement to the wait_for_complete_response E2E step to log the parsed streaming response data before assertions. This aids in diagnosing intermittent skills E2E test failures by making the actual response payload visible in CI output.

Type of change

  • Refactor
  • New feature
  • Bug fix
  • CVE fix
  • Optimization
  • Documentation Update
  • Configuration Update
  • Bump-up service version
  • Bump-up dependent library
  • Bump-up library or tool used for development (does not change the final image)
  • CI configuration change
  • Konflux configuration change
  • Unit tests improvement
  • Integration tests improvement
  • End to end tests improvement
  • Benchmarks improvement

Tools used to create PR

Identify any AI code assistants used in this PR (for transparency and review context)

  • Assisted-by: Cursor
  • Generated by: N/A

Related Tickets & Documents

  • Related Issue LCORE-3027

Checklist before requesting a review

  • I have performed a self-review of my code.
  • PR has passed all pre-merge test jobs.
  • If it is a core feature, I have added thorough tests.

Testing

Verified via CI pipeline. The added print statement outputs the parsed streaming response data during E2E test runs, providing visibility into the response payload when skills feature tests execute.

Summary by CodeRabbit

  • Tests
    • Added diagnostic output of parsed response data during end-to-end response completion checks.

@coderabbitai

coderabbitai Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Walkthrough

The response completion step now prints context.response_data after parsing and before checking response status and completion.

Changes

Response Debugging

Layer / File(s) Summary
Completion step debug output
tests/e2e/features/steps/llm_query_response.py
Prints parsed context.response_data before the existing status and completion assertions.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Suggested reviewers: radofuchs


Important

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

❌ Failed checks (1 error)

Check name Status Explanation Resolution
Security And Secret Handling ❌ Error tests/e2e/features/steps/llm_query_response.py:96 prints context.response_data, exposing response text, IDs, tool data, and errors in CI logs. Replace the raw print with bounded/redacted logger output and avoid logging the full payload; emit only a safe summary or hash.
✅ Passed checks (6 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title matches the change: it describes adding debug logging for the skills E2E flow.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Performance And Algorithmic Complexity ✅ Passed PASS: tests/e2e/features/steps/llm_query_response.py:94-97 adds one debug print after parsing; no loops, repeated API calls, pagination, or unbounded buffers were introduced.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
✨ Simplify code
  • Create PR with simplified code

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/e2e/features/steps/llm_query_response.py`:
- Around line 94-96: Update the response handling around
_parse_streaming_response so the safe, redacted diagnostic is emitted
immediately after parsing and before context.response.raise_for_status().
Preserve the existing status validation and ensure failure responses still print
the parsed payload for debugging.
- Line 96: Replace the raw context.response_data print in the response-handling
step with the project logger initialized as logger = get_logger(__name__). Emit
only a bounded, redacted diagnostic that excludes response text, conversation
IDs, tool calls/results, and stream errors; do not log the full payload.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: e391f36d-e32b-4cde-ae8b-49bc477af444

📥 Commits

Reviewing files that changed from the base of the PR and between 4cb2e83 and a20a917.

📒 Files selected for processing (1)
  • tests/e2e/features/steps/llm_query_response.py
📜 Review details
⏰ Context from checks skipped due to timeout. (18)
  • GitHub Check: list_outdated_dependencies
  • GitHub Check: Pyright
  • GitHub Check: unit_tests (3.12)
  • GitHub Check: unit_tests (3.13)
  • GitHub Check: integration_tests (3.13)
  • GitHub Check: integration_tests (3.12)
  • GitHub Check: build-pr
  • GitHub Check: Pylinter
  • GitHub Check: spectral
  • GitHub Check: mypy
  • GitHub Check: E2E: library mode / ci / group 1
  • GitHub Check: E2E: library mode / ci / group 2
  • GitHub Check: E2E: library mode / ci / group 3
  • GitHub Check: E2E: server mode / ci / group 1
  • GitHub Check: E2E: server mode / ci / group 2
  • GitHub Check: E2E: server mode / ci / group 3
  • GitHub Check: E2E Tests for Lightspeed Evaluation job
  • GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-0-7-on-pull-request
🧰 Additional context used
📓 Path-based instructions (4)
**/*

📄 CodeRabbit inference engine (Custom checks)

**/*: Flag meaningful O(n^2)+ algorithms on non-trivial inputs, including handlers and Kubernetes list operations.
Flag N+1 patterns that list items and then query once per item, including Kubernetes API and database access.
Flag expensive work inside loops, including API calls, JSON parsing, and regex compilation.
Flag unbounded growth in caches, watchers, or buffers when eviction or limits are missing.
Flag missing pagination or limits on list operations and API endpoints.
Flag secrets or tokens logged in plaintext or hardcoded in source.
Flag API endpoints missing authentication or authorization.
Flag injection vulnerabilities, including SQL injection, command injection, and path traversal.
Flag sensitive data leaked in API responses, WebSocket messages, or logs.
Flag Kubernetes Secrets and Red Hat secrets missing OwnerReferences.

Files:

  • tests/e2e/features/steps/llm_query_response.py
**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

**/*.py: Use absolute imports for internal Python modules and check pyproject.toml for existing dependencies and versions before adding dependencies.
All Python modules must begin with descriptive docstrings; package __init__.py files must contain brief package descriptions.
Use logger = get_logger(__name__) from log.py for module logging.
Use Final[type] for constants and check constants.py for shared constants before defining new ones.
Define type aliases at module level for clarity.
All functions must have Google-style docstrings and complete parameter and return type annotations.
Use typing_extensions.Self for model validators, modern union syntax such as str | int, and Optional[Type] for optional values.
Use descriptive, action-oriented snake_case names for functions, such as get_, validate_, and check_.
Do not modify parameter objects in place when producing results; return a new data structure instead.
Use async def for I/O operations and external API calls.
Handle APIConnectionError from Llama Stack integrations.
Use standard logger levels appropriately: debug for diagnostics, info for normal execution, warning for unexpected or potentially problematic conditions, and error for serious failures.
All classes must have descriptive Google-style docstrings, complete attribute type annotations, and specific types instead of Any.
Use PascalCase for classes with descriptive suffixes, including Configuration, Error/Exception, Resolver, and Interface where applicable.
Use ABC and @abstractmethod for abstract interfaces.
Follow Google Python docstring conventions and include Parameters, Returns, Raises, and Attributes sections when applicable.

Files:

  • tests/e2e/features/steps/llm_query_response.py
tests/e2e/**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

Use Behave with Gherkin for end-to-end tests; place step definitions under tests/e2e/features/steps/.

Files:

  • tests/e2e/features/steps/llm_query_response.py
**/*.{py,toml,yaml,yml,json}

📄 CodeRabbit inference engine (AGENTS.md)

Run and satisfy the project's configured quality checks, including Black, Pylint, Pyright, Ruff, pydocstyle, type checks, and Bandit security scanning.

Files:

  • tests/e2e/features/steps/llm_query_response.py
🧠 Learnings (3)
📚 Learning: 2026-04-07T09:20:26.590Z
Learnt from: radofuchs
Repo: lightspeed-core/lightspeed-stack PR: 1467
File: tests/e2e/features/steps/common.py:36-49
Timestamp: 2026-04-07T09:20:26.590Z
Learning: For Behave-based Python tests, rely on Behave’s Context layered stack for attribute lifecycle: Behave pushes a new Context layer when entering feature scope (before_feature) and again for scenario scope (before_scenario). Attributes assigned inside given/when/then steps live on the current scenario layer and are automatically removed when the scenario ends. As a result, step-set attributes should not be expected to persist across scenarios or features, and manual cleanup in after_scenario/after_feature is generally unnecessary for attributes set in step functions. Only perform manual cleanup for attributes that you set explicitly in before_feature/before_scenario, since those live on the respective feature/scenario layers.

Applied to files:

  • tests/e2e/features/steps/llm_query_response.py
📚 Learning: 2026-04-13T13:39:54.963Z
Learnt from: radofuchs
Repo: lightspeed-core/lightspeed-stack PR: 1490
File: tests/e2e/features/environment.py:206-211
Timestamp: 2026-04-13T13:39:54.963Z
Learning: In lightspeed-stack E2E tests under tests/e2e/features, it is intentional to set context.feature_config inside Background/step functions (scenario-scoped Behave layer). The environment.py after_scenario restore logic should only restore configuration when context.scenario_lightspeed_override_active is True; this flag is set by configure_service only when a real config switch occurs (so restore does not run for scenarios without a switch). Additionally, steps/common.py’s module-level _active_lightspeed_stack_config_basename is used to prevent re-applying the same config across subsequent scenarios, ensuring scenario_lightspeed_override_active stays False after the first apply. Therefore, reviewers should not “fix” this flow as if feature_config were incorrectly scoped or if after_scenario restoration is missing—config switching and restoration are meant to happen exactly once per actual switch, not redundantly per scenario.

Applied to files:

  • tests/e2e/features/steps/llm_query_response.py
📚 Learning: 2026-06-24T13:45:37.249Z
Learnt from: Jdubrick
Repo: lightspeed-core/lightspeed-stack PR: 1971
File: src/utils/markdown_repair.py:31-36
Timestamp: 2026-06-24T13:45:37.249Z
Learning: In the lightspeed-stack repository, docstrings must use the section header name "Parameters:" (not "Args:") for function arguments, even if the project references Google Python docstring conventions. Ensure docstrings follow the project’s established "Parameters:" header format for any documented function parameters.

Applied to files:

  • tests/e2e/features/steps/llm_query_response.py

Comment on lines 94 to +96
context.response_data = _parse_streaming_response(context.response.text)
context.response.raise_for_status()
print(f"Response data: {context.response_data}")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Emit the diagnostic before raise_for_status().

When the response has a non-2xx status, Line 95 raises before Line 96 executes, so the payload is unavailable for precisely those failures the debug output should help diagnose. Move the safe, redacted diagnostic immediately after parsing or include it in error handling.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/e2e/features/steps/llm_query_response.py` around lines 94 - 96, Update
the response handling around _parse_streaming_response so the safe, redacted
diagnostic is emitted immediately after parsing and before
context.response.raise_for_status(). Preserve the existing status validation and
ensure failure responses still print the parsed payload for debugging.

"""Wait for the response to be complete."""
context.response_data = _parse_streaming_response(context.response.text)
context.response.raise_for_status()
print(f"Response data: {context.response_data}")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Do not print the full response payload to CI logs.

context.response_data includes response text, conversation IDs, tool calls/results, and stream errors. Raw printing can expose sensitive data to anyone with CI-log access and produce unbounded output. Use the project logger with a bounded/redacted diagnostic instead.

As per coding guidelines, module logging must use logger = get_logger(__name__), and sensitive data must not be leaked in logs.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/e2e/features/steps/llm_query_response.py` at line 96, Replace the raw
context.response_data print in the response-handling step with the project
logger initialized as logger = get_logger(__name__). Emit only a bounded,
redacted diagnostic that excludes response text, conversation IDs, tool
calls/results, and stream errors; do not log the full payload.

Source: Coding guidelines

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant